Five perspectives on modern memory management: Systems, hardware and theory

Dynamic memory management is a vital feature of all modern programming languages. Yet, heap allocation is difficult for the application programmer to manage correctly and for the systems developer to implement efficiently. Unfortunately, and for very good reasons, memory management errors are not confined to novices: at least one study has shown that up to 40% of programmer time is wasted on hunting down memory management errors. Automatic dynamic memory management (garbage collection) relieves the programmer of the burden of making a global decision – can an object no longer be used and thus is it safe to free the memory that it occupies? – in a local context. The usual alternative of adding memory management book-keeping detail to module interfaces is undesirable because it weakens abstractions and reduces extensibility. Garbage collection, on the other hand, uncouples the problem of memory management from interfaces instead of dispersing it throughout the code. The field of memory management continues to present new challenges. The widespread use of languages such as Java, Perl and Python in substantial applications of commercial importance has brought garbage collection into the mainstream: it is more important than ever before. At one extreme, server applications are starting to demand very large numbers of threads, multi-gigabyte heaps and high throughput. At the other end, the advent of Microsoft’s Common Language Infrastructure and C# in particular on the one hand, and the prevalence of Java applications in small devices such as phones on the other, means that garbage-collected applications will become prevalent on the desktop and in the pocket. In this special issue of the Science of Computer Programming, we present five very different perspectives on modern memory management. Erlang [1] is a strict, functional programming language that supports concurrency, communication, distribution and fault tolerance. It is a key component of products and services for companies like Ericsson, Nortel and T-Mobile (for example, in Ericsson’s AXD301 which provides the ATM switch infrastructure for BT’s network in the UK). Whereas many programming languages expect to support between a few and a few hundred threads, Erlang applications may use hundreds of thousands of concurrent processes. It is therefore vital that Erlang processes be lightweight and highly responsive. In the first article in this special issue, Efficient Memory Management for Concurrent Programs that Use Message Passing, Sagonas and Williamson show how the particular characteristics of Erlang can be exploited to provide efficient garbage collection with short pause times. Their key contribution is a hybrid architecture combining process-local heaps that can be collected independently with a shared area for messages passed between processes. A static analysis is used to speculatively allocate data that might be used as a message in the shared area. An incremental, generational collector imposes little overhead on the user program and, because Erlang has no destructive update, requires no costly barrier mechanisms. The goal of the Cyclone project [4] is a safe, low-level language. Cyclone is a dialect of C that uses programmersupplied annotations, a type system, a flow analysis and run-time checks to ensure that programs are safe. One of the first challenges that must be surmounted in such a project is making memory management safe. In Safe Manual Memory Management in Cyclone, Swamy, Hicks, Morrisett, Grossman and Jim describe how statically scoped regions and tracked pointers can be used to construct a variety of safe memory management abstractions. Cyclone pointers may be aliasable, unique (alias-free) or reference-counted; a compile-time flow analysis checks correct usage of unique pointers. Unique pointers can also be used to build new memory management abstractions such as dynamic allocation arenas, thereby avoiding the limitations imposed by stack-like, last-in–first-out disciplines. Finally, they describe their